refactor(aztec-nr): use constructor methods for MessageDelivery variants#23596
Merged
Conversation
…/richer-enums # Conflicts: # docs/docs-developers/docs/resources/migration_notes.md # noir-projects/noir-contracts/contracts/test/custom_sync_state_contract/src/main.nr
vezenovm
approved these changes
May 27, 2026
vezenovm
left a comment
vezenovm
left a comment
Contributor
There was a problem hiding this comment.
I like this refactor a lot. Provides more API flexibility + moves us towards stronger types in aztec-nr and away from primitive types.
danielntmd
pushed a commit
to danielntmd/aztec-packages
that referenced
this pull request
Jun 4, 2026
BEGIN_COMMIT_OVERRIDE refactor(aztec-nr): use constructor methods for MessageDelivery variants (AztecProtocol#23596) docs: update testing_contracts.md for two-crate aztec new layout (AztecProtocol#23617) fix: drop usage of include and indexof on types that support equals (AztecProtocol#23595) fix: unused ts expressions in tests (AztecProtocol#23621) feat(aztec-nr): Get tagging index for constrained delivery (AztecProtocol#23359) feat!: demote auth registry to non-protocol contract (AztecProtocol#23106) feat(aztec-nr)!: embed BoundedVec max length in validation requests (AztecProtocol#23622) fix: regenerate standard contract addresses after auth registry demotion (AztecProtocol#23640) feat(aztec-nr): encrypt handshake log for indistinguishability (AztecProtocol#23638) feat!: demote public_checks to non-protocol contract (AztecProtocol#23217) fix: noir precommit re-staging inside worktrees (AztecProtocol#23628) END_COMMIT_OVERRIDE
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The current
MessageDeliveryAPI uses a struct-with-constants pattern (MessageDelivery.OFFCHAIN) that is inflexible: callers can only select from a fixed set ofu8values with no room for additional configuration. For example, a caller might want to set the sender for tags instead of using the transaction default.Our fix
MessageDeliveryis now a proper struct with named constructors (MessageDelivery::offchain(),MessageDelivery::onchain_unconstrained(),MessageDelivery::onchain_constrained()). This pattern is extensible: constructors can accept parameters in the future without changing the callsite shape.For example, to support a custom sender for tags, the API could be extended to:
All callsites, documentation, and code examples are updated to use the new syntax. A migration note is included.